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CROSS-REFERENCE TO RELATED APPLICATIONS 

This application claims the benefit of U.S. Provisional Application No. 60/111,292, filed 
12/07/98. 

5 BACKGROUND OF THE INVENTION 
Field of the invention: 

The present invention relates to the field of netvc^orked computer systems. More 
specifically, the invention relates to a method and apparatus for remote installation of network 
10 drivers and software in a computer system. 



Background information: 

:p Computer systems often communicate information with sources external to the computer, 

for example, over one or more networks. This information is frequently sent as smaller packets 
^5|5 of information and transported over various network topologies, such as 'Ethernet". The routing 
J: of the information is by various formats, or network protocols, for example, TCP/IP. In order for 

an end computer to receive and utilize the information, the computer must have the appropriate 
ilj network protocol driver (hereinafter termed protocol driver). A protocol driver is usually 
Q connected in a computer's internal conamunication path between the network connection and an 
end application. 

Figure 1 is a block diagram Illustrating media access control (MAC) unit to application 
communication according to the prior art. The block diagram is a simplified illustration of a 
computer system utilizing the Microsoft® Windows operating systems (e.g., Windows 95, 

25 Windows 98, Windows NT, etc.) (Manufactured by Microsoft Corp. of Redmond, Washington). 
Information is initially received, for example, as packets, from the network by a media access 
control unit (MAC) 120. The MAC 120 is used to control access to the physical transmission 
medium on a network. The MAC 120 routes the information to the NDIS 115. The NDIS 1 15 
is a network driver interface. The NDIS 1 15 receives the information and routes it to the 

30 appropriate protocol driver(s) shown as protocol driver(s) 1 10 (e.g., a TCP/IP driver). The 
protocol driver 1 10 receives the information and routes it to the WESfSOCK 105. The 
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WINSOCK is a interface program (Manufactured by Microsoft Corp. of Redmond, Washington). 
The WINSOCK 105 receives the information and routes it to the appropriate application(s) 100. 

At certain times it is useful to insert a different protocol driver into the existing 
5 communication path (hereinafter termed the binding) between the MAC 120 and the protocol 
driver(s) 1 10. When a new protocol driver is added to the existing binding, a new binding must 
be established which incorporates the new protocol driver. The new binding links the new 
protocol driver to the MAC 120. 

10 Figure 2 is a block diagram illustrating a prior art technique of inserting an intermediate 

driver in the system of Figure 1 . The intermediate driver is used to install a new protocol driver 

■ IKS'): 

on an existing computer system. This method is more fully described in the "README" file for 
P the ImSamp intermediate driver sample, IMSAMP,SYS, (Available from Microsoft Corp. of 
\ fi Redmond, Washington) , 

las 

p In this method, the intermediate protocol driver 125 is bound to the NDIS 115. At 

Number 1, the MAC 120 routes information to the NDIS 115. At Number 2, the NDIS 1 15 
I if receives the information and routes it to the intermediate protocol driver 125. Within the 
=4 intermediate protocol driver 125, the information is passed to the inserted protocol driver 130 
So through the new binding. From the inserted protocol driver 130, the information is converted to 
the MAC layer format by MAC 135 in the intermediate protocol driver 1 10. At Number 3, the 
information is then passed from the MAC 135 to the NDIS 1 15 to enable continued routing of 
the information to the protocol driver 1 10. From the protocol driver 1 10, the information passes 
to the WINSOCK 105 and on to the appropriate application(s) 100. 

25 

The above-described prior art method has several limitations that impact its utiUty, 
particularly when implemented on networks with large numbers of computers. First, the 
intermediate protocol driver software must be manually installed on each computer. An 
individual, for example, a systems technician, must physically go to every computer and 
30 manually load the intermediate protocol driver software and the new protocol driver. This may 
involve a substantial time investment when many computers are involved simply to load the 
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software. It also results in lost productivity for the computer operator as in-use applications must 
be exited during installation. Second, to enable the operation of the new protocol driver, the 
computer must be shut down and restarted. The necessity of shutdown and restart also requires 
that in-use applications be saved and exited. Where large numbers of computers are involved, 
this may result in large losses of productivity and can be disruptive of services provided by the 
network. 

It should be noted that some operating systems provide mechanisms to remotely distribute 
software over the network. These systems generally include a server to which several computers 
are connected. In a remote distribution, the new software is loaded onto the server and then 
distributed to each of the individual computers, thus reducing installation time. However, even 
with the remote distribution, the installation of an intermediate protocol driver requires a user 
(e.g., a system technician) exit existing in-use applications, perform the installation, shut down 
the computer system, and then restart the computer system to enable operation of the new 
protocol driver. 
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BREF SUMMARY OF THE INVENTION 

The present invention provides a method and apparatus for remote installation of network 
drivers and software. According to one embodiment of the invention, there is provided a 
computer implemented method for transmitting an installation application and a rerouting driver 
5 from a remote host to a first target computer on a network; the first target computer including a 
network driver interface that provides for conmiunication between one or more media access 
control units and one or more protocol drivers according to a set of bindings. The remote host 
transmits to the first target computer a command to cause the first target computer to execute the 
installation application. In response to receipt of the command, the first target computer, 

10 executes the installation application. Responsive to execution of the installation application, the 
first target computer causes the modification of the network driver interface to insert the 

S rerouting driver into the one or more communication paths provided by the set of bindings 

F without restarting the first target computer. 
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I. 



BRIEF DESCRIPTION OF THE DRAWINGS 

The invention may best be understood by referring to the following description and 
accompanying drawings which are used to illustrate embodiments of the invention. In the 
drawings: 

5 

Figure 1 is a block diagram illustrating MAC to application communication according to 
the prior art; 

Figure 2 is a block diagram illustrating a prior art technique of inserting an intermediate 
10 driver in the system of Figure 1 ; 

! S Figure 3 is a block diagram illustrating the static patching of a rerouting driver between a 

F MAC and protocol drivers according to one embodiment of the invention; 

'J|5 Figure 4 is a flow diagram illustrating the remote installation of the rerouting driver 

according to one embodiment of the invention; 

Figure 5 is a flow diagram illustrating the operation of the install application 325 
\| according to one embodiment of the invention; 

;io 

Figure 6 is a flow diagram illustrating the operation of the static patching code 365 
according to one embodiment of the invention; 

Figure 7 is a block of unmodified instruction code from the NDIS 315 prior to insertion 
25 of static patching code 365; 

Figure 8 is a diagram illustrating the patching of the NDIS 315 to call to one of 
template(s) 350 according to one embodiment of the invention; 

30 Figure 9 is a flow diagram illustrating the operation of one of template(s) 350 according 

to one embodiment of the invention; 
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Figure 10 is a block diagram illustrating a network with distributed packet based security 
according to one embodiment of the invention; 

Figure 1 1 A is a block diagram illustrating the installation and partial operation of a 
rerouting driver for packet based security according to one embodiment of the invention; 

Figure 1 IB is a block diagram illustrating another part of the operation of the rerouting 
driver for packet based security according to one embodiment of the invention; 

Figure 12 is a flow diagram illustrating the disabling and re-enabUng of access to code in 
a multiprocessor system according to one embodiment of the invention; 

Figure 13 is a block diagram illustrating the dynamic patching of a rerouting driver 
between MACs and protocol drivers according to one embodiment of the invention; and, 

Figure 14 is a flow diagram illustrating the operation of the dynamic patching code 1360 
according to one embodiment of the invention. 
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DETAILED DESCRIPTION OF THE INVENTION 

In the following description, numerous specific details are set forth to provide a thorough 
understanding of the invention. However, it is understood that the invention may be practiced 
without these specific details. In other instances, well-known connections, structures and 
5 techniques have not been shown in detail in order not to obscure the invention. 

A method and apparatus for remote installation of network drivers and software in a 
computer system is described. To accomplish this, the invention allows for the remote 
installation of a rerouting driver in such a way that operation of the computer system can 
10 continue during installation, and the computer system does not require a shutdown and restart to 
enable operation of the rerouting driver. 

; ".^ i 

* Sxiy 

Figure 3 is a block diagram illustrating the static patching of a rerouting driver between a 
ill MAC and protocol drivers according to one embodiment of the invention. Existing or future 
1 25 bindings resulting from the insertion of the rerouting driver are shown in solid Unes. Existing or 
:=P future bindings rerouted by the insertion of the rerouting driver are shown in dashed lines. 

•^l Figure 3 shows, similar to the prior art, network information, such as packets, received 

%| by one or more MACs 320 A-i being routed to the NDIS 315. Prior to the installation of the 
^30 static patch, the NDIS 315 routes the information to one or more protocol driver(s) 310. The 

protocol driver(s) 3 10 then routes the information to the WINSOCK 305 for further routing to 

the appropriate application(s) 300, 

Either via remote distribution from a remote host (not shown) or by directly loading, an 
25 install application 325, DLL 330, and rerouting driver 335 are copied to memory in the target 
computer and the install application 325 is started. The install application 325 through the 
interface provided by the DLL 330 (see letters A and B) requests the rerouting driver 335 be 
loaded. The install application 325 requests control code 340 execute binding code 345 to 
estabUsh a new binding between the rerouting driver 335 and at least one MAC 320A (see letter 
30 C). The install application 325 then requests control code 340 install the static patching code 365 
(see letter D). At letter E, the static patching code 365 inserts template jump(s) 375 from the 
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NDIS 315 to template(s) 350 in the rerouting driver 335. Particularly, NDIS 315 contains code 
with generic calls to perform information conamunication between the MAC(s) 320 and protocol 
driver(s) 310. The static patch replaces each of these calls with a jump to one of the template(s) 
350. Details of the static patching code installation are later described herein with reference to 
5 Figure 6. The binding may be continued for each MAC 320. After installation, the install 
application 325 may be deleted. At the completion of the static patch, the rerouting driver 335 
has been inserted at the NDIS 315 between the MAC(s) 320 and the protocol driver(s) 310. 

At Number 1, following the static patch, information received by one or more MAC(s) 
10 320 is routed to the NDIS 315. At Number 2, information destined for protocol driver(s) 3 10 is 
then jumped from one of template jump(s) 375 to one of template(s) 350 in the rerouting driver 
% 335. At Number 3, information received by the template(s) 350 can be routed to the inserted 
=|S code 355, The inserted code 355 may be a new protocol driver, or another program, for example, 
m a security program that can prevent further routing of the information. When the inserted code 
^i5 355 is completed, the information is routed back to the template(s) 350. At Number 4, the 
=|I template(s) 350 may route the information on to the protocol driver 310, or the information can 
i be discarded if it is not desirable to pass the information further. At Number 5, a return jump to 
[Jl the NDIS 3 15 is executed. 

"'iH 

'Jlo It should be noted that, following installation of the static patching code 365, there are 

two types of bindings to the NDIS 315 over which the same information will be communicated. 
One binding was established on the initial binding of the NDIS 315 to the rerouting driver 335; 
this binding is represented in Figure 3 as the dashed line between the NDIS 315 and the rerouting 
driver 335. The second type of binding is the original binding(s) between the NDIS 315 and the 

25 protocol driver(s) 3 10; these binding(s) are represented in Figure 3 as the dashed line between the 
NDIS 315 and the protocol driver(s) 310. These bindings are essentially removed by the static 
patching because the rerouting driver 335 intercepts the call to the protocol driver 310 and later 
issues the call to the protocol driver(s) 310 on completion of the inserted code 355. To ensure 
that only one transmission of the information is routed to protocol driver 310, the rerouting driver 

30 335 examines the incoming transmissions to determine if the information is destined for one of 
the protocol driver(s) 310 or itself. Mormation destined for one of the protocol driver(s) 310 is 
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passed onto the inserted code 355. Information destined for the rerouting driver 335 can be 
discarded or be utilized for other purposes^ for example, security purposes. 

Figure 4 is a flow diagram illustrating the remote installation of the rerouting driver 335 
5 according to one embodiment of the present invention. At block 400, install application 325, the 
DLL 330, and rerouting driver 335 aire remotely copied into the memory of a target computer 
networked from a remote host (not shown). At block 410, install application 325 is started using 
well-known remote service request techniques. It is to be noted that remote installation requires 
the manual installation of the software only at the remote host computer. A systems technician 
10 loads the software once at the remote host and then the software is copied to the other individual 
computers on the network. Thus, a systems technician does not waste productive time loading 
installation software at each individual computer in a network. 

if I Rgure 5 is a flow diagram illustrating the operation of the install q)plication 325 

;fc according to one embodiment of the invention. Once the install application 325 is started, at 
C block 500, install application 325 identifies at least one MAC 320X. When a MAC 320X is 
Lj. identified, at block 510, install application 325 requests rerouting driver 335 be loaded. At block 
^ Jf 520, install application 325 requests control code 340 execute binding code 345 to bind rerouting 
' J driver 335 to MAC 320X. At block 530, install application 325 requests control code 340 
So execute the static patching code 365. Operation of the static patching code 365 is further 
described herein with reference to Figure 6. Once the static patching code 365 has been 
executed, at block 540, the install application 325 optionally requests DLL 330 to bind the install 
application 325 to any other MAC(s) 320. When all the MAC(s) 320 have been bound, the 
install application 325 may be deleted. 

25 

Figure 6 is a flow diagram illustrating the operation of the static patching code 365 
according to one embodiment of the invention. At block 600, control code 340 identifies the 
operating system version of the computer system. This step is necessary as static patching code 
365 is selectively configured for different operating system versions. The selective configuration 
30 is predetermined by evaluating each version of an operating system to determine the offsets of 
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the protocol driver(s) CALLs in the instruction code of the NDIS 315. These addresses can be 
determined using well-known debugging techniques. 

At block 610, control code 340 identifies whether offset data is available for the 
5 identified operating system version to allow the installation of static patching code 365. If the 
offset data is not present, control code 340 returns to install application 325 for user notification 
(block 660). If the offset data is present, control code 340 identifies the starting memory address 
of NDIS 315 instruction code (see block 620). In block 630, control code 340 disables access to 
at least the specific code in the NDIS 315 that will be patched. In certain single processor 
10 computer systems, block 630 can be performed by disabling all interrupts. Techniques for 
performing block 630 in a multiprocessor computer system are later described herein with 
I'S reference to Figure 12. 

i j j In block 640, the instruction code in the NDIS 315 is statically patched with static 

:|5 patching code 365 by overwriting the instructions in each predetermined memory address (using 
C the predetermined offsets) with template jump(s) 375 to template(s) 350 in the rerouting driver 
335. The overwriting of the instructions with the static patch code 365 is later described herein 
^ y with reference to Figures 7 and 8. 

20 At block 650, control code 340 reenables access to the code in NDIS 315 that is now 

patched. In block 660, control code 340 returns to install application 325. The disabling and re- 
enabling of access to the code being patched in the NDIS 315 allows the patching (and thus the 
rerouting driver installation) to be performed without exiting in-use applications and a system 
shutdown/restart. 

25 

Figure 7 is a block of unmodified instruction code from the NDIS 315 prior to insertion 
of static patching code 365. When NDIS 315 reaches instruction "CALL X" in the instruction 
stack, NDIS 315 calls the protocol driver currently identified by the variable "X" (e.g., one of the 
protocol driver(s) 310). During installation of static patching code 365, the instruction "CALL 
30 X" is overwritten with a template jump 375. The overwrite replaces the "CALL X" with a jump 
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to one of the template(s) 350 in the rerouting driver 335, so that the template 350 instructions are 
executed instead of the call to the intended routines for the protocol driver X. 



Figure 8 is a diagram illustrating the patching of the NDIS 3 15 to call to one of 
5 templates(s) 350 according to one embodiment of the invention. The patching involves 

overwriting of the "CALL X" instruction with a template jump 375 — a "JUMP" to a template 
350 address in the rerouting driver 335. It should be noted that the length of the jump instruction 
overwrites both "CALL X" and "<INSTRUCTION 920>" previously shown in Figure 7. The 
"JUMP" is then made to the address of the template 350. The template 350 may include new 
10 instructions (e.g., instruction 950) in which additional inserted code 355 may be executed or 

called. At the completion of additional inserted code 355, the template 350 would then execute 
I jJ the "CALL X" and the other replaced instructions (e,g.,"<INSTRUCTION 920>") and jump back 
P to the next address in NDIS 3 15, i.e., "<INSTRUCTION 930>". In this manner, a static patch to 
ifi the rerouting driver 335 is introduced in the NDIS 315. This overwriting at specific memory 
;35 addresses in the instruction code of the NDIS 3 15 is repeated until all the calls for that operating 
:f system are overwritten with different template jumps 375 which correspond to different 
|\ templates 350. 

Figure 9 is a flow diagram illustrating the operation of one of template(s) 350 according 
;|0 to one embodiment of the invention. At block 900, a jump from a template jump 375 in the 
NDIS 3 15 to a template 350 is made responsive to a MAC request. As earlier discussed, this 
MAC request can be to a protocol driver 3 10 or to the rerouting driver 335 due to a dual binding 
estabUshed during installation of the static patching code 365. At block 910, the template 350 
determines if the information is destined for the rerouting driver 335. 

25 

If the information was not destined for the rerouting driver 335, then it was destined for 
one of the protocol driver(s) 3 10 and the information was received through the static patching 
code 365. At block 920, the information is then routed to the inserted code 355. At completion 
of the inserted code 355, the information may or may not be routed to the appropriate protocol 
30 driver 3 10 via a CALL, depending upon the outcome of the inserted code 355 instructions. At 
block 930, if the call is to be routed on to the appropriate protocol driver(s) 310, upon return 
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from the inserted code 355, the appropriate protocol driver 3 10 is called. At block 950, on return 
from the call, then a jump back from the template 350 to the NDIS 315 is executed. 
Alternatively, if the call was not to be routed on to the protocol driver(s) 310, the jump back to 
the NDIS 315, at block 950, is executed without routing the information to the protocol driver 
5 310. 

If the information is destined for the rerouting driver 335, the information was received 
through the binding of the NDIS 315 to the rerouting driver 335. At block 940, the template 350 
would then execute a predetermined prescribed action. This action could be to discard the 
10 information, or to route the information to other code instructions. At block 950, on return from 
the prescribed action, the return jump back to the NDIS 3 15 is executed. 

p Thus, one embodiment of the present invention provides a method and apparatus for the 

ifi remote installation of network drivers and software from a central host computer. The present 

•;|5 invention may provide substantial advantages over the prior art techniques, especially when used 

:p on large networks of computers. 

ry First, the remote installation of the present invention only requires a systems technician to 

y install the application on a host computer for distribution to individual computers connected to 

io the host. The remote installation alleviates the need for the system technician to manually load 
the software at each individual computer. 

Second, the remote installation can be accomplished while the in-use system remains 
operating and does not require the shutdown and startup of the system to enable the operation of 
25 the new drivers and/or software. This alleviates the need to save and exit existing applications 
during installation and may result in a preservation of productive work time and system access. 

Third, the prior art described with reference to Figure 2 required that the information 
received by the intermediate protocol driver be converted by the intermediate protocol driver 
30 back into the MAC layer format for routing through the NDIS to the protocol drivers. Thus, a 
packet is converted from the MAC layer to the protocol layer format twice (a first time when 
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originally transmitted from the MAC to the rerouting driver through the NDIS, and a second time 
when transmitted from the intermediate driver to the protocol driver through the NDIS), In 
contrast, the present invention does not require the second conversion to a MAC layer format to 
route the information from the rerouting driver to the protocol driver. 

5 

Although the above-described embodiment of the present invention was described in 
terms of a remote installation, it is to be understood that the invention can be manually installed 
on individual computers if so desired. 

10 Alternative Embodiments 

The above-described embodiment of the present invention provides a method and 
:Sl apparatus for the remote installation of network drivers and software. Another embodiment of 
=P the present invention utilizes the remote installation embodiment to install a distributed packet 
if ^ based security system on one or more individual computers of a network. 

lis 

:C Currently networked computers are vulnerable to electronic intrusions over the network, 

i\ for example, via the Internet. To restrict access to the computers on a network, computer 

networks often employ computer security measures that limit access to the network based on 
=y selected parameters . 

:|o 

Figure 10 is a block diagram illustrating a network with distributed packet based security 
according to one embodiment of the invention. Initial access security to the switching network is 
provided by a firewall. A firewall generally blocks access to a system except to those given 
access rights on an individual basis. The access requirements must be continually updated to 
25 remain current and effective. With large computer networks, maintaining current individual 
access authorizations can be time consuming and difficult to maintain. Therefore, another 
security measure, independent of the an access list, is a packet based security system. 

Due to the ease of installation and/or low cost, the packet based security system can be 
30 installed on one or more of the server(s) and/or one or more of the individual computers 1000 
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A - i. The packet based security system evaluates the packets of information received over the 
network according to some predetermined standard. 

In one embodiment of the present invention, a rerouting driver for a distributed packet 
based security system is provided which can evaluate received network information against 
predetermined and/or dynamic parameters. Based on those parameters, the system can either 
prevent or allow continued transmission of the information to a protocol driver. In this manner, 
undesirable information is stopped at the NDIS level and does not enter into the protocol driver 
or application level of a computer. Additionally, the invention provides the capability to save the 
non-transmitted information for further security evaluation. Further, the invention can be 
distributed and then installed on individual computers through a remote host while in operation 
(without shutdown and restart of each computer system). 

Figure 1 1 A is a block diagram illustrating the installation and partial operation of a 
rerouting driver for packet based security according to one embodiment of the invention. 
Network information received by one or more MAC(s) 1 120 is routed to the NDIS 1115. Prior to 
the installation of the rerouting driver 1 135, the NDIS 1115 routes the information to the protocol 
driver 1110, The protocol driver 1110 then routes the information to the WINSOCK 1 105 for 
further routing to the appropriate application 1 100. 

As previously described, the install/security application 1 125, DLL 1 130, and rerouting 
driver 1 135 are copied to memory in the target computer and the install/security application 1 125 
is started. The install/security application 1 125 through the interface provided by the DLL 1 130 
(see letters A and B) requests the rerouting driver 1 135 be loaded. The install/security 
application 1 125 requests control code 1 140 execute binding code 1 145 to establish a new 
binding between the capturing unit 1 160 in the rerouting driver 1 135 and at least one MAC 1 120, 
referred to as MAC 1 120X (see letter C). The install/security application 1 125 then requests 
control code 1 140 install the static patching code 1 165 (see letter D). At letter E, the static 
patching code 1165 inserts template jumps 1 175 from the NDIS 1115 to templates 1150 in the 
rerouting driver 1 135. The binding to the capturing unit 1 160 continues for each of the 
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remaining MACs 1 120 A-i. At the completion of the static patch, the rerouting driver 1 135 has 
been inserted at the NDIS 1115 between the MAC(s) 1 120 and the protocol driver(s) 1 1 10, 



As earlier described, there are now at least two bindings for each MAC. One binding was 
5 established on the initial binding of the NDIS 1 1 15 to the capturing unit 1 160 in the rerouting 
driver 1 135; this binding is represented in Figure 1 1 A as the dashed line between the NDIS 1115 
and the capture unit 1 160, The remaining binding(s) are the original bindings between the NDIS 
1115 and the protocol driver(s) 1 1 10 which have been diverted to the rerouting driver 1 135 by 
the static patch (not shown). As a result, for a given packet received from a MAC, the NDIS 
10 1115 will attempt to CALL at least one of the protocol driver(s) 1110 and the capturing unit 

1 160. However, due to the static patch, each attempt will result in entry into one of the 
; template(s) 1 150. The circled numbers 1-5 in Figure 1 lA illustrate when the NDIS 1115 
HP attempts to CALL one of the protocol driver(s) 1110, while the circled numbers in Figure 11 B 
ifl illustrates when the NDIS 1115 attempts to call the cq)turing unit 1 160. 
S5 

|J With reference to Figure 1 1 A, at Number 1, a request is made to the NDIS 1115 from a 

MAC 1 120. At Number 2, a jump to a template 1 150 is received from the template jump 1 175 in 
ijl the NDIS 1115 (upon an attempted call to the protocol driver 1 1 10). The template 1 150 

determines if the request was destined for the rerouting driver 1 135. If the answer is yes, then 
;20 further actions related to packet based security are taken as later described herein with reference 

to Figure 1 IB. If the answer is no, then the information was destined for a protocol driver 1110 

(the topic of Figure 1 1 A). 

At Number 3, the information is then routed to the filter unit 1 155. The filter unit 1 155 
25 may include code to evaluate the information to determine if the information should be passed to 
the intended protocol driver 1 1 10. IF it is not desirable to pass the information further, the 
information can be discarded or further utilized by the filter unit 1 155 and, at Number 5, a jump 
back to the NDIS 1 1 15 is executed. If the information is determined to be acceptable, the 
information is routed back to the template 1 150. At Number 4, the template 1 150 then routes the 
30 information to the protocol driver 1 1 10 by performing the CALL X extracted form the NDIS 
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1115 during the patching. At Number 5, on return from the protocol driver 11 10 to the template 
1 1 50, a return jump to the NDIS 1 1 1 5 is executed. 

Figure 1 IB is a block diagram illustrating another part of the operation of the rerouting 
5 driver for packet based security according to one embodiment of the invention. Particularly, 
when the NDIS 1 1 15 is attempting to call the rerouting driver 1 135. In this case, at Number 2 a 
jump to template 1 150 is again received from the template jump 1 175 in the NDIS 1115 (upon 
the attempted call the rerouting driver 1 135). The template 1 150 determines the request was 
destined for the rerouting driver 1 135. At Number 3, the information is passed to the capturing 
10 unit 1 160 (e.g., by performing the Ci\LL X extracted from the NDIS 1115 during patching). The 
capturing unit 1 160 then saves the information according to predetermined instructions for 
further security evaluation, and at Number 4, a jump back to the NDIS 1 1 15 is executed. 

if j In one embodiment, further security evaluation of the information saved by the capturing 

;J5 unit 1 160 (hereinafter termed the date) can be performed by another application, such as the 
=|S install/security application. The captured information originates in the system address space 

(e.g., where the protocol drivers, rerouting driver, NDIS and MACs reside). Many applications 
ill need access to data originating from the system address space. The typical way this is 
y accomplished is by making system calls (e.g., I/O APIs). These system calls are not very 
§0 efficient in their use of CPU resources, typically copying memory to and from user address space 
into the system address space. In addition, these system calls also create at least two costly CPU 
state transitions from user to supervisor mode and back to user mode. One option to minimize 
the overhead is to run more of the code in the system address space. Doing this increases the 
difficulty in debugging the software and has the disadvantage of not being able to take advantage 
25 of multiple CPUs on many operating systems. 

In one embodiment, a shared memory buffer is created between device drivers in system 
address space and application(s) in the user space. In this way an application can get access to 
data in system address space without any more overhead than a memory read. However, it is 
30 necessary to prevent conditions where a CPU executing driver code may be simultaneously 
modifying memory being accessed by a CPU executing the application. 
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To prevent this situation of simultaneous use, in one embodiment, two counters may be 
used to signal the state of the buffer. One counter ("write count") is the count of the number of 
items written into the memory buffer. Another counter ("read count") is the count of number of 
5 items read from the buffer. Only the producer modifies the "write count" and only the consumer 
modifies the "read count," If the "read count" is not equal to the "write count", then valid data is 
contained in the buffer. One example of this is shown below. 

Application execution: 
10 Loop; 

if "read count" <> "write count" 
Get next buffer 
42 Read next item 

if ^ Process item 

■ 95 Licrement read count 

:C Else 

, Wait for signal 

ill endif 

jo Go to loop 

System address execution: 
Loop: 

Wait for incoming data 
25 Allocate empty buffer 

If allocation failed 

Discard data 

Go to loop 

endif 

30 Process data 

Write data into buffer 
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Increment write count 

If "write count" = "1 + read count" ; put data into an empty buffer 

Send signal 
Go to loop 

5 

Figures 1 1 A and 1 IB illustrate one embodiment of the present invention that provides 
packet-based security through utilization of the double binding to the NDIS 1115. Particularly, 
any bindings from the NDIS 1 1 15 to the protocol driver(s) 1 1 10 are used to route packets 
through the rerouting driver to the protocol driver(s) 1110. However, the bindings of the 
10 MAC(s) 1 120 to the rerouting driver 1 135 are used as a mechanism to capture the packets for 

later security evaluation. By providing a separate path for the capturing of the packets for 
^2 security evaluation, a separate context is provided for this capturing process. As is well known 
=p in the art, the provision of a separate context allows greater programming flexibility during the 
if I capturing process. 

In an alternative embodiment, the double bindings are not used. Rather, either the 
/ >^ packets are not captured for later security evaluation or the packets are captured during the 
ry routing from the NDIS 1 1 15 to the protocol driver(s) 1 1 10. In a system in which the packets are 
'.J captured during the routing from the NDIS 1 1 15 to the protocol driver(s) 1110, each of the 
^^|0 MAC(s) 1 120 need not be bound to the rerouting driver 1 135 (the optional step 540 from Figure 
5 is not performed). 

For example, in one embodiment of the present invention, using only a single binding to 
the NDIS 1 1 15, information that is deemed acceptable by the filter unit 1 155, is routed to the 
25 template 1 150 for routing to the appropriate protocol driver 1 1 10. Information that is deemed 
not acceptable by the filter unit 1 155, is then routed back to the template 1 150 for routing to the 
capturing unit 1 160. 



Thus, there has been described alternative embodiments of the present invention which 
30 provide distributed packet based security. The embodiments provide for the intercept and 

evaluation of information packets received over a network by a rerouting driver with associated 
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software. After evaluation, the information may be allowed continued routing to the protocol 
driver. Alternatively, the information may be stopped and/or saved for further security 
evaluations. The embodiments can be remotely distributed and installed on individual computers 
on a remote host while in operation without shutdown and restart of the computer system. 

5 

Further, while the present embodiment describes a system to provide distributed packet 
based security, other embodiments may be practiced by providing other evaluation parameters in 
the filter unit. For example, the filter unit could contain parameters to filter and capture 
information with particular routing information, and in this way monitor utilization of the 
10 network. 



5^ Also, it should be understood that although the alternative embodiments were described 

in terms of a remote installation, the embodiments can be manually installed on individual 
If { computers if so desired. 

35 

M To avoid the shutdown and restart, access to predetermined instruction code in the NDIS 

, should be disabled and then re-enabled to effect the overwriting of the memory addresses with 

i V static patch code. As above described, this can be done on certain single processor systems by 
disabling and reenabling interrupts. Each of the above-described embodiments can be 
alternatively implemented in multiprocessor systems by disabling and re-enabling access as 
described below. 

Figure 12 is a flow diagram illustrating the disabling and re-enabling of access to code in 
a multiprocessor system according to one embodiment of the invention. At block 1200, in a 

25 given central processing unit (CPU), the code that is to be modified is brought into the cache of 
the given CPU and is overwritten with "blocking code" to create a first version of the code. The 
blocking code will prevent other CPUs from progressing past this code. While the blocking code 
can be implemented any number of ways, one way is to write code that causes the CPU to loop 
around a serializing instruction. As a result, any of the other CPUs (i.e., the CPUs not 

30 performing the patch), cannot access (are disabled) the code to be modified. 
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At block 1210, the first version of the code is written from the given CPU's cache into 
shared memory. As a result, if another CPU attempts to execute the code to be modified, it will 
access the blocking code from the shared memory. 

At block 1220, the code beyond the blocking code can now be modified in the given 
CPU's cache as required to create a second version of the code. For example, in one 
embodiment, the code can be overwritten with template jumps to effect the static patch of the 
NDIS. 

At block 1230, the second version of the code is written from the given CPU's cache into 
shared memory. 

At block 1240, the previously inserted blocking code in the given CPU's cache is now 
overwritten with the desired code to create a third version of the code. 

At block 1250, the third version of the code (without the blocking code) is written into 
shared memory. As a result, the patched code is in the shared memory and any CPU that now 
attempts to execute the code at that address will get the patched code. 

Utilizing the above technique allows installation of the above-described alternative 
embodiments of the present invention on single and multiple processor systems. 

The above-described embodiments have been described in terms of a static patch to 
predetermined instruction code addresses on the NDIS. Static patching requires that the offsets 
for the calls in the NDIS be predetermined. However, in certain situations, it is desirable to 
automate the identification of the C/lLL addresses in the NDIS and/or to accommodate different 
and/or new operating system versions utilizing different addresses. Accordingly, one 
embodiment provides a dynamic patch technique that patches individual instruction code 
locations as information is received from them by the rerouting driver. In this manner, 
incrementally each CALL is patched until all the specific instruction locations from which 
information was passed are patched. 
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Figure 13 is a block diagram illustrating the dynamic patching of a rerouting driver 
between MACs and protocol drivers according to one embodiment of the invention. As 
previously described, the install application 1325, DLL 1330, and rerouting driver 1335 are 
copied to memory in the target computer and the install application 1325 is started. The install 
5 application 1325 through the interface provided by the DLL 1330 requests the rerouting driver 
1335 be loaded. The rerouting driver 1335 then requests control code 1340 execute binding code 
1345 to establish a new binding between the dynamic patching code 1360 in the rerouting driver 
1335 and every MAC 1320 A-i, 

10 There is now one binding that will route information to the dynamic patching code 1360 
in the rerouting driver 1335. This binding is represented in Figure 13 as the dotted line between 

^ the NDIS 1315 and the dynamic patching code 1360. Now the rerouting driver 1335 waits to 

if'! 

,g receive a packet of information in order to determine the location in the NDIS 1315 instruction 
^1; code where it must insert a patch. 

m 

11 At Number 1, information is received by a MAC 1320 from the network. This 
information is forwarded to the NDIS 13 15 for routing to the appropriate protocol driver(s) 1310 

i Ij and/or the rerouting driver 1335. The NDIS 1315 forwards the information to the protocol driver 
1310 as no patches of the NDIS 1315 have been made. Due to the multiple bindings, the NDIS 

=S0 1315 additionally forwards the same information to the dynamic patching code 1360. The 

dynamic patching code 1360 determines if a dynamic patch should be made to the instruction 
code address that sent the information. 

At Number 3, if a dynamic patch should be made to the instruction code address that sent 
25 the information, a dynamic patch is executed by the dynamic patching code 1360. The dynamic 
patching code 1360 will overwrite the specified code in the NDIS 1315 with a template jump 
1375 to a template 1350 in the rerouting driver 1335. The next time information is passed 
through the NDIS 1315 at that instmction code location, information destined for protocol driver 
1310 will be routed to the dynamic patching code 1360 in the rerouting driver 1335 for further 
30 action as described below with reference to Figure 14. 
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Figure 14 is a flow diagram illustrating the operation of the dynanaic patching code 1360 
according to one embodiment of the Invention. At block 1400, the dynamic patching code 1360 
receives a call As the dynamic patching code is dually bound, this call could be from one of the 
templates or from the NDIS 1315. At block 1410, the dynamic patching code 1360 determines if 
the call is from one of the templates. 

If the answer is yes, the call is routed to the inserted code for further action (see block 
1440). On completion of the inserted code, the call is returned to the template for further action 
(see block 1450). 

If the answer in block 1410 is no, the call was received from an unpatched part of the 
NDIS 1315. Therefore, action must be taken to patch the instruction code in the NDIS 1315. At 
block 1420, the call information is accessed from the CALL stack. At block 1430, the call is 
patched as previously described. From block 1430, control passes to block 1450. 

Thus, there has been described one embodiment of the present invention which remotely 
installs protocol drivers using a dynamic patch of the NDIS. As some information must pass 
from the NDIS to the protocol driver to establish the location of the NDIS instruction code to be 
patched, the dynamic patch is not as initially effective as the static patch embodiments earlier 
described. 

Embodiments can use combinations of the static/dynamic patching techniques. For 
example, if the data on a given operating system is available, the static patching technique is 
used. However, if the data is not available, the user is notified and/or the dynamic patching 
technique is used. As another example, the static patching technique could be used for all known 
calls and the dynamic patching technique could be installed in case one or more calls were 
missed. 

While the invention has been described in relation to remote installation of protocol 
drivers and packet based security systems, the present invention may also be used for installation 
of other software that utilizes drivers that must be bound to the NDIS to be operational. In 
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addition, while embodiments of the invention have been described in relation to a packet based 
security system, alternative embodiments could be implemented such that other inserted code 
could be utilized to perform other operations with the redundant code. 

5 It is to be noted that the items shown in Figures 3 - 14 are stored and executed on a 

computer system. Such a computer system stores and communicates (internally and with other 
computer systems over a network) code and data using machine readable media, such a magnetic 
disks, optical disks, random access memory, read only memory, carrier waves, signals, etc. In 
addition, while one embodiment is described in which the parts of the present invention are 
10 implemented in software, alternative embodiments can implement one or more of these parts 
using any combination of software, firmware, and/or hardware. 

=P While the invention has been described in terms of several embodiments, those skilled in 

ifi the art will recognize that the invention is not limited to the embodiments described. The method 

;1 5 and apparatus of the invention can be practiced with modification and alteration witiiin the spirit 

S and scope of the appended claims. The description is thus to be regarded as illustrative instead of 

i ^ limiting on the invention. 
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is claimed is: 

A machine-readable medium having stored thereon sequences of instructions which, 
when executed by a processor, cause the processor to perform the acts of: 

disabling access to at least a first section of code in a network driver interface, 
wherein the network driver interface provides for conmiunication between one or more 
media access control units and one or more protocol drivers in a computer system 
according to a set of bindings; 

patching the first section of code to cause the insertion of a rerouting 
driver into the one or more conmiunication paths provided by the set of bindings; and 

re-enabling access to the patched first section of code. 

The machine-readable medium of claim 1 wherein the patching is static patching. 

The machine-readable medium of claim 2 wherein the static patching includes inserting a 
template jump fi-om the network driver interface to a template in the rerouting driver. 

The machine-readable medium of claim 3 wherein the template jumps are inserted in the 
network driver interface so that a CALL instruction to the protocol driver is replaced with 
a JUMP to the template in the rerouting driver, the template containing the CALL 
instruction. 

The machine-readable medium of claim 2 wherein the patching the first section of code 
creates at least one new binding between the network driver interface and the rerouting 
driver. 
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The machine-readable medium of claim 5 wherein the at least one new binding provides 
for communication between one or more media access control units and a capturing unit 
in the rerouting driver. 

The machine-readable medium of claim 6 wherein the capturing unit is used to intercept 
communications over the at least one new binding. 

The machine-readable medium of claim 1 wherein the patching is dynamic patching. 

The machine-readable medium of claim 8 wherein the dynamic patching includes 
establishing a new binding between at least one media access control unit and dynamic 
patching code in the rerouting driver, and inserting a template jump in the network driver 
interface to a template in the rerouting driver. 

The machine-readable medium of claim 9 wherein the template jumps are inserted in the 
network driver interface so that a CALL instruction to the protocol driver is replaced with 
a JUMP to the template in the rerouting driver, the template containing the CALL 
instruction. 

A computer implemented method comprising: 

transmitting from a remote host to a first target computer on a network an 
installation application and a rerouting driver; 

transmitting from the remote host to the first target computer a command to cause 
the first target computer to execute the installation application; 

the first target computer, responsive to receipt of the command, executing the 
installation application, wherein the first target computer includes a network driver 
interface that provides for communication between one or more media access control 
units and one or more protocol drivers according to a set of bindings; and 

the first target computer, responsive to executing the installation application, 
causing the modification of the network driver interface to insert the rerouting driver into 
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the one or more communication paths provided by the set of bindings without restarting 
the first target computer. 

The computer implemented method of claim 1 1 wherein the modification of the network 
driver interface is by static patching. 

The computer implemented method of claim 12 wherein the static patching further 
comprises inserting template jumps from the network driver interface to templates in the 
rerouting driver. 

The computer implemented method of claim 13 wherein the template jumps are inserted 
in the network driver interface so that a CALL instruction to the protocol driver is 
replaced with a JUMP to the template in the rerouting driver, the template containing the 
CALL instruction. 

The computer implemented method of claim 1 1 wherein the modification of the network 
driver interface is by dynamic patching„ 

The computer implemented method of claim 15 wherein the dynamic patching further 
comprises establishing a new binding between at least one media access control unit and 
dynamic patching code in the rerouting driver, and inserting a template jump in the 
network driver interface to a template in the rerouting driver. 

The computer implemented method of claim 16 wherein the template jumps are inserted 
in the network driver interface so that a CALL instruction to the protocol driver is 
replaced with a JUMP to the template in the rerouting driver, the template containing the 
CALL instruction. 
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A computer system comprising: 
a protocol driver; 
a media access control unit; 

a network driver interface to store a first binding defining a communication path 
between the protocol driver and the media access control unit, the network driver 
interface coupled to communicate packets with the media access control unit, the network 
driver interface patched to communicate the packets with a rerouting driver; and 

the rerouting driver being coupled to communicate the packets with the protocol 

driver. 

The computer system of claim 18, the rerouting driver further comprising static patching 
code. 

The computer system of claim 18, the rerouting driver further comprising dynamic 
patching code. 

The computer system of claim 18, the rerouting driver further comprising a capture unit 
to store in a buffer one or more of the packets for evaluation. 

The computer system of claim 21, the network interface to also store a second binding 
defining a communication path between the rerouting driver and the media access control 
unit; and, the capture unit to store in the buffer the packets destined for the rerouting 
driver. 

A rerouting driver for remotely installing network drivers and software in a computer 
system without restarting the computer system following installation, the computer 
system having an operating system in which a network driver interface provides 
communication of information between at least one media access control unit and at least 
one protocol driver on the computer system, the rerouting driver comprising: 
control code, for controlling the rerouting driver; 
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binding code, for establishing at least one binding at the network driver interface 
so that the rerouting driver is bound to at least one media access control unit; 

patching code, for inserting template jumps into at least a first section of code in 
the network driver interface, the template jumps providing jumps to templates in the 
rerouting driver so that information from at least one media access control unit destined 
for at least one protocol driver is rerouted to the rerouting driver; 

at least one template, for receiving information from at least one template jump in 
the network driver interface; 

inserted code, for evaluating rerouted information received by the template jumps. 

The rerouting driver of claim 23 wherein the control code identifies a starting memory 
address of the network driver interface instruction code and disables access to the first 
section of code, and further wherein the patching code, following the disabling of access, 
operates to overwrite the first section of code and additional pre-determined memory 
addresses so that all the pre-determined memory addresses are patched. 

The rerouting driver of claim 23 wherein the patching code responsive to receipt of 
information being sent from the network driver interface, determines the instruction code 
address that sent the information and overwrites the first section of code at that address so 
that memory addresses are incrementally patched as information is received from the 
network driver interface. 
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A method for disabling and re-enabling access to code in a multiprocessor system having 
a shared memory and a network driver interface comprising: 

selecting a first section of code in a first central processing unit that is to be 
modified; 

writing the first section of code into the cache memory of the first central 
processing unit; 

overwriting a portion of the first section of code in cache memory with blocking 
code to create a first version of code; 

writing the first version of code into shared memory; 

modifying the first version of code in the cache memory to create a second version 
of code, wherein a portion of the code following the blocking code is overwritten with 
template jumps to effect a static patch of the network driver interface; 

writing the second version of code into shared memory; 

modifying the second version of code in the cache memory with code to create a 
third version of code, wherein the blocking code is overwritten to remove the blocking 
code; and 

writing the third version of code into shared memory. 

The method of clahn 26 wherein the fu^t section of code is located in the network driver 
interface. 

A machine-readable medium having stored therein instructions, which when executed, 
cause a set of one or more processors to perform the following: 

disabling access to a first section of code, the first section of code to be executed 
when to provide a communication path between a media access control unit and an 
application, the first section of code including a generic call; and 

overwriting the first section of code with a second section of code whose 
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execution causes execution flow to be rerouted to a third section of code in a rerouting 
driver, the second section of code being no larger than the first section of code, the third 
section of code, when executed, completing the conmiunication path and returning 
execution flow, the third section of code including additional code not present in the first 
section of code that is now inserted into the conmiunication path. 

The machine-readable medium of claim 28 wherein the second section of code contains a 
template jump to a template in the third section of code. 



31 



Attorney Docket No.: 003845.P002 



ABSTRACT OF THE DISCLOSURE 

A method and apparatus for remote installation of network drivers and software. The 
present invention provides for the remote installation of a rerouting driver into the network driver 
interface in the path between one or more media access control units and one or more protocol 
drivers in a computer system. Code in the network driver interface is disabled, patched to insert 
the rerouting driver, and then re-enabled. The disabling and re-enabling of the code is performed 
such that the computer system does not have to be restarted following installation of the patch. 
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Attorney's Docket No.: 003845.P002 Patent 

DECLARATION AND POWER OF ATTORNEY FOR PATENT APPLICATION 



As a below named inventor, I hereby declare that: 

My residence, post office address and citizenship are as stated below, next to my name. 

I believe I am the original, first, and sole inventor (if only one name is listed below) or an original, 
first, and joint inventor (if plural names are listed below) of the subject matter which is claimed and 
for which a patent is sought on the invention entitled 
A METHOD AND APPARATUS FOR REMOTE INSTALLATION OF NETWORK DRIVERS AND 
SOFTWARE 



the specification of which 

X is attached hereto. 

was filed on as 

United States Application Number 

or PCT International Application Number 

and was amended on . 

(if applicable) 

I hereby state that I have reviewed and understand the contents of the above-identified 
specification, including the claim(s), as amended by any amendment referred to above. I do not 
know and do not believe that the claimed invention was ever known or used in the United States of 
America before my invention thereof, or patented or described in any printed publication in any 
country before my invention thereof or more than one year prior to this application, that the same 
was not in public use or on sale in the United States of America more than one year prior to this 
application, and that the invention has not been patented or made the subject of an inventor's 
certificate issued before the date of this application in any country foreign to the United States of 
America on an application filed by me or my legal representatives or assigns more than twelve 
months (for a utility patent application) or six months (for a design patent application) prior to this 
application. 

I acknowledge the duty to disclose all information known to me to be material to patentability as 
defined in Title 37, Code of Federal Regulations, Section 1.56. 

I hereby claim foreign priority benefits under Title 35, United States Code, Section 1 19(a)-(d), of any 
foreign application(s) for patent or inventor's certificate listed below and have also identified below 
any foreign application for patent or inventor's certificate having a filing date before that of the 
application on which priority is claimed: 
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Prior Foreign Application(s) 



Priority 
Claimed 



(Number) (Country) (Day/MonthA'ear Filed) Yes No 



(Number) (Country) (Day/Month/Year Filed) Yes No 



(Number) (Country) (Day/MontliA'ear Filed) Yes No 

i hereby claim the benefit under title 35, United States Code, Section 1 19(e) of any United States 
provisional application(s) listed below: 

60/111.292 12/07/98 

(Application Number) Filing Date 



(Application Number) Filing Date 



1 hereby claim the benefit under Title 35, United States Code, Section 120 of any United States 
application(s) listed below and, insofar as the subject matter of each of the claims of this application 
is not disclosed in the prior United States application in the manner provided by the first paragraph 
of Title 35, United States Code, Section 112, 1 acknowledge the duty to disclose all information 
known to me to be material to patentability as defined in Title 37, Code of Federal Regulations, 
Section 1.56 which became available between the filing date of the prior application and the national 
or PCT international filing date of this application: 



(Application Number) Filing Date (Status -- patented, 

pending, abandoned) 



(Application Number) Filing Date (Status - patented, 

pending, abandoned) 

I hereby appoint the persons listed on Appendix A hereto (which is incorporated by reference and a 
part of this document) as my respective patent attorneys and patent agents, with full power of 
substitution and revocation, to prosecute this application and to transact all business in the Patent 
and Trademark Office connected herewith. 

Send correspondence to Lisa A. Norris , BLAKELY, SOKOLOFF, TAYLOR & 

(Name of Attorney or Agent) 
ZAFMAN LLP, 12400 Wilshire Boulevard 7th Floor, Los Angeles, California 90025 and direct 
telephone calls to Lisa A, Norris , (408) 720-8598. 

(Name of Attorney or Agent) 
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I hereby declare that all statements made herein of my own knowledge are true and that all 
statements made on information and belief are believed to be true; and further that these 
statements were made with the knovi/ledge that willful false statements and the like so made 
are punishable by fine or imprisonment, or both, under Section 1001 of Title 18 of the United 
States Code and that such willful false statements may jeopardize the validity of the 
application or any patent issued thereon. 

Full Name of Sole/First Inventor Clinton Edward Lum 



Inventor's Signature Date 

Residence Foster Citv. CA Citizenship USA 

(City, State) (Country) 

Post Office Address 1340 Swordfish Street. Foster Citv. California 94404 



Full Name of Second/Joint Inventor 

Inventor's Signature Date 

Residence Citizenship 

(City, State) (Country) 

Post Office Address 



Full Name of Third/Joint Inventor 



Inventor's Signature Date . 

Residence Citizenship . 



(City, State) (Country) 
Post Office Address 



Full Name of Fourth/Joint Inventor 



Inventor's Signature Date . 

Residence Citizenship . 



(City, State) (Country) 
Post Office Address 
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APPENDIX A 



William E. Alford, Reg. No. 37,764; Farzad E. Amini, Reg. No. P42,261 ; Aloysius T. C. AuYeung, Reg. No. 
35.432; William Thomas Babbitt, Reg. No. 39,591; Carol F. Barry, Reg. No. 41,600; Jordan Michael 
Becker, Reg. No. 39,602; Bradley J. Bereznak, Reg. No. 33,474; Michael A. Bernadicou, Reg. No. 35,934; 
Roger W. Blakely. Jr., Reg. No. 25,831 ; Gregory D. Caldwell, Reg. No. 39,926; Ronald C. Card, Reg. No. 
P44,587; Thomas M. Coester, Reg. No. 39,637; Stephen M. De Klerk, under 37 C.F.R. § 10.9(b); Michael 
Anthony DeSanctis, Reg. No. 39,957; Daniel M. De Vos, Reg. No. 37,813; Robert Andrew Diehl, Reg. No. 
40,992; Matthew C. Pagan, Reg. No. 37,542; Tarek N. Fahmi, Reg. No. 41,402; James Y. Go, Reg. No. 
40,621; James A. Henry, Reg. No. 41,064; Willmore F. Holbrow III, Reg. No. P41,845; Sheryl Sue 
Holloway, Reg. No. 37,850; George W Hoover 11, Reg. No. 32,992; Eric S. Hyman, Reg. No. 30,139; Dag 
H. Johansen, Reg. No. 36,172; William W. Kidd, Reg. No. 31,772; Erica W. Kuo, Reg. No, 42,775; Michael 
J. Mallie, Reg. No. 36,591; Andre L. Marais, under 37 C.F.R. § 10.9(b); Paul A. Mendonsa, Reg. No. 
42,879; Darren J. Milliken, Reg. 42,004; Lisa A. Norris, Reg. No. 44,976; Chun M. Ng, Reg. No. 36,878; 
Thien T. Nguyen, Reg. No. 43,835; Thinh V. Nguyen, Reg. No. 42,034; Dennis A. Nicholls, Reg. No, 
42,036; Kimberley G. Nobles, Reg. No. 38,255; Daniel E. Ovanezian, Reg, No. 41,236; Babak Redjaian, 
Reg. No. 42,096; Wiiliam F. Ryann, Reg. 44,313; James H. Salter, Reg. No. 35,668; William W. Schaai, 
Reg. No. 39,018; James C. Scheller, Reg. No. 31,195; Jeffrey Sam Smith, Reg. No. 39,377; Maria 
McCormack Sobrino, Reg. No. 31,639; Stanley W. Sokoloff, Reg. No. 25,128; Judith A. Szepesi, Reg. No. 
39,393; Vincent P. Tassinari, Reg. No. 42,179; Edwin H. Taylor, Reg. No. 25,129; John F. Travis, Reg. 
No. 43,203; George G. C. Tseng, Reg. No. 41,355; Joseph A. Twarowski, Reg. No. 42,191; Lester J. 
Vincent, Reg. No. 31,460; Glenn E. Von Tersch, Reg. No. 41,364; John Patrick Ward, Reg. No. 40,216; 
Charles T. J. Weigell, Reg. No. 43,398; Kirk D. Williams, Reg. No. 42,229; James M. Wu, Reg. No. 
P45,241; Steven D. Yates, Reg. No. 42,242; Ben J. Yorks, Reg. No. 33,609; and Norman Zafman, Reg. 
No. 26,250; my patent attorneys, and Andrew C. Chen, Reg. No. 43,544; Justin M. Dillon, Reg. No. 
42,486; Paramita Ghosh, Reg. No. 42,806; and Sang Hui Kim, Reg, No. 40,450; my patent agents, of 
BLAKELY, SOKOLOFF, TAYLOR & ZAFMAN LLP, with offices located at 12400 Wilshire Boulevard, 7th 
Floor, Los Angeles, California 90025, telephone (310) 207-3800, and James R. Thein, Reg. No. 31,710, 
my patent attorney. 
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APPENDIX B 



Title 37, Code of Federal Regulations, Section 1 .56 
Duty to Disclose Information Material to Patentability 

(a) A patent by its very nature is affected with a public interest. The public interest is best served, 
and the most effective patent examination occurs when, at the time an application is being examined, the 
Office is aware of and evaluates the teachings of all information material to patentability. Each individual 
associated with the filing and prosecution of a patent application has a duty of candor and good faith in 
dealing with the Office, which includes a duty to disclose to the Office all information known to that individual 
to be material to patentability as defined in this section. The duty to disclosure information exists with respect 
to each pending claim until the claim is cancelled or withdrawn from consideration, or the application becomes 
abandoned. Information material to the patentability of a claim that is cancelled or withdrawn from 
consideration need not be submitted if the information is not material to the patentability of any claim 
remaining under consideration in the application. There is no duty to submit information which is not material 
to the patentability of any existing claim. The duty to disclosure all information known to be material to 
patentability is deemed to be satisfied if all information known to be material to patentability of any claim 
issued in a patent was cited by the Office or submitted to the Office in the manner prescribed by §§1.97(b)-(d) 
and 1 .98. However, no patent will be granted on an application in connection with which fraud on the Office 
was practiced or attempted or the duty of disclosure was violated through bad faith or intentional misconduct. 
The Office encourages applicants to carefully examine: 

(1 ) Prior art cited in search reports of a foreign patent office in a counterpart application, and 

(2) The closest information over which individuals associated with the filing or prosecution of a 
patent application believe any pending claim patentably defines, to make sure that any material information 
contained therein is disclosed to the Office,, 

(b) Under this section, information is material to patentability when it is not cumulative to 
information already of record or being made or record in the application, and 

(1 ) It establishes, by itself or in combination with other information, a prima facie case of 
unpatentability of a claim; or 

(2) It refutes, or is inconsistent with, a position the applicant takes in: 

(i) Opposing an argument of unpatentability relied on by the Office, or 

(ii) Asserting an argument of patentability. 

A prima facie case of unpatentability is established when the information compels a conclusion that a claim is 
unpatentable under the preponderance of evidence, burden-of-proof standard, giving each term in the claim 
its broadest reasonable construction consistent with the specification, and before any consideration is given to 
evidence which may be submitted in an attempt to establish a contrary conclusion of patentability. 

(c) Individuals associated with the filing or prosecution of a patent application within the 
meaning of this section are: 

(1 ) Each inventor named in the application; 

(2) Each attorney or agent who prepares or prosecutes the application; and 

(3) Every other person who is substantively involved in the preparation or prosecution of the 
application and who is associated with the inventor, with the assignee or with anyone to whom there is an 
obligation to assign the application. 

(d) Individuals other than the attorney, agent or inventor may comply with this section by 
disclosing information to the attorney, agent, or inventor. 
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